Overview

The basic premise here is that we want to be able to get a broader overview of what is happening in the system by looking at data across subsystems (alerts, operations, etc) at once. For instance, instead of looking at alerts on each of my JBossAS resources, I should be able to view all alerts across the system (and then potentially filter them). Instead of looking at the results of operations for a single resource or compatible group, I want to see all of my operations at once (and then potentially filter them).

The dashboard attempts to provide this functionality, but does not scale well to very larger inventories where you'll generally need to sort through vast quantities of data to find precisely what you're looking for. The dashboard doesn't providing sorting, pagination, or searching of the results - it only gives the "last 10 operations executed" or "5 most recent alerts". Thus, in order to make this useful for users, we want to provide them with a way to quickly navigate through the data from each subsystem, which means 'search'.

However, instead of spending time writing custom search interfaces for each subsystem of data we want to sift through, a better approach might be to provide a way to somehow automatically build up a search interface. The requirements for such a tool are below. A mock-up for what the dynamic interface for search alerts would look like (with saved search patterns) is on the right.

Target Subsystems

• alert history

• operation history

• availability history - is this verging on reporting?

• problem resource

• events history

• resource configuration history

• deployments / package changes

The Details

1. entry point method

   • tab approach

     • when we get too many tabs, then make them multi-layered?

     • how to order the tabs? - wouldn't necessarily map to the tab layout for resources...would it?

   • simple, alpha-ordered select list of different views <-- simpler

2. extensible dynamic search interface

   • interface that provides a dynamic list of search criteria

   • each criteria can then provide a list of applicable choices

     • applicable choices should be wrt the search criteria

       • show counts next to each criteria choice

         • allow counts to be toggled

       • suppress display of 0-count choices

   • example: alerts definitions

     • allow search on priority, which has possible values of LOW, MEDIUM, HIGH

     • but if there aren't any LOW alerts, values will only be MEDIUM and HIGH

     • display will show counts parenthetically: MEDIUM (34), HIGH (56) in the drop-down

3. special base component

   • will provide common functionality across all subsystem views

   • will expose a list of shared criteria and applicable criteria choices

   • common criteria list

     • resource type: type name, category (platform, server, service)

     • resource group name

     • resource name

     • resource's current availability (UP / DOWN)

     • time period - this is a shared criteria, but needs to be implemented differently by each subsystem view (see "date picker supports two modes" below)

   • sticky navigation: allow navigation between different subsystem views via "entry point method", but make the current options within the "common criteria list" sticky; this will allow navigation back and forth across the subsystems and will keep the context consistent for data correlation purposes

4. query generation

   • generate the table data query from the selected criteria choices

   • generate the list of criteria choices for unselected criteria off of the results from the main query

     • count queries off of each groupby to generate item counts

   • example: problem resources

     • assume availabilityType search option already selected, choice was DOWN

     • allow search on resourceType field too, but limit the values in drop-down to types that are DOWN

     • display will show counts of only DOWN'ed types, parenthetically: JBossAS Server (2), IIS (1)

5. metadata

   • allow the searchable fields to be specified through a simple descriptor

     • enables search interface to be built up while requiring little to no coding

   • allow the field name to be customized, i.e. does not have to match the entity field name being searched on

   • allow the renderer to be specified through the descriptor (combobox, input text, date picker, checkbox)

     • combobox should be multi-select

     • input text render will additionally support auto-suggest features (richfaces supports this)

       • allow multiple instances of auto-suggest input text fields to mirror the multi-select capabilities of combobox inputs

       • little "plus" icon to add another one somewhere that ajax-adds the new field

     • date picker supports two modes (do we need an explicit 'simple' vs 'advanced' option, or is that a better way to display this choice)

       • last X units in Y period (e.g, last 5 days, last 8 hours, etc)

       • combination of before this date and/or after that date, each can be N/A

   • expression processing

     • each different search / filter param will be AND'ed together

     • multiple instances of the same search / filter param (multi-select combobox, multiple instances of auto-suggest input text) will be OR'ed together

   • allow developer to choose the search field ordering for consistency of rendering

6. ui considerations

   • rendering based on ui data from the metadata

   • consistent field ordering

   • integration with rich table component, in particular the DataModel

     • this enables us to add dynamically rendered search interfaces to ANY tabular display

   • javascripty expand/collapse of the search interface

   • automatically store last search - this is an extension to the already auto-persisted pagination/sorting stuff

   • support ability to save search patterns

     • searches are associated with tabular display, so will hang off of PageControl too

   • selection of saved search pattern populates rest of UI panel with correct options

     • search button needs to be clicked separately?

     • this allows for you to select various saved searches, and quickly see what they are

       • e.g. HIGH alerts for the last 7 days or RESTART operations on JBAS resources in the last 4 hrs

     • saved searches should have its own rollup window

     • display result counts next to each saved search

   • toggle for count display

   • restrict the display of result set data so that the interface has a maximum time for rendering

     • e.g., some result set for combobox is huge (~1000), if count > 20 convert to input text field and log WARNing

     • either that or cap the list at 20, and print "..." after that?

7. pivoted views

   • supported views

     • subsystem data view - default audit entries shown in the table

     • resource view - generic resource composite table with counts of subsystem data audit entries that match the given search / filter params

     • resource group view - generic resource group composite table with counts of resources & subsystem data audit entries that match the given search (i.e., any resourceGroup containing any resource containing any data that matches the filter, group by resourceGroup and count the authz-aware resources that have data matching the filter, as well as the raw counts of the data that match that filter by group)

   • interface layout

     • flat - use composites to show the view, and counts to show the grouped values

     • hierarchical - allow the user to choose a permutation of (data,resource,group)

       • first item in list is the primary display

       • each item in the primary display is an ajax-y, expandable, nested table (richfaces supports this naturally) - problem here MIGHT be how to effectively search large nested tables (i say MIGHT because i wonder if our datatable extensions would "just work" to give you sortable, paginated nested data)

8. enhanced support for cluster views

   • if i wanted to see all alerts that are on ANY resource in some cluster...

     • create mixed, recursive group on the fly? (at the time the search is triggered)

     • group definition enhancement: mechanism to create both compatible (cluster) and mixed recursive groups at the same time, instead of one or the other

       • problem with this solution is that the group membership could get stale, and would need explicit recalculation by some end user

     • flatten the resource hierarchy - mechanism that enables a single, non-recursive query to gather ALL descendants of a resource or resourceGroup

       • this would be auto-calculating, but would need tight integration with inventory operations (commit / manualAdd / createNew, uninventory, delete) to make sure it was kept up to date (though we've done similar things like this with auto-creating alert templates, so it's not like this strategy is ground-breaking)

       • authorization would change: instead of explicit/implicit it would be more like hierarchical/unrolled. if recursive bit is set: subject-role-group-unrolled. if recursive bit is NOT set: subject-role-group-hierarchical (this is what we use today).

       • the benefit of this is that recursive groups have practical NO computation cost, because the hierarchical is already flattened

       • furthermore, it would enable us to provide a checkbox in the dynamic search UI to "include children" resources in the search; if it's selected then we follow the "unrolled" authz path; if not, we follow the "hierarchical" path; since the query is built up on the fly anyway, it would be easily to switch in between these two models

9. permissions

   • need to support admin versus non-admin queries for each

   • list of criteria might be different depending on user too (to allow admin to search on more than a user)

10. saved search portlet (the ultimate eat-your-own-dogfood)

    • use the dynamic search interface to allow people to search their saved search patterns

      • admin users can search all paterns, non-admin users can only see their own

      • criteria:

        • user (who does this pattern belong to [only applicable to admins])

        • pattern name

        • entity type / view

    • clicking a saved search in the table will wisk the user to the appropriate view within the application

11. export

    • serialization options: comma-delimited, excel spreadsheet, rss/atom feed

    • data selection options: ALL, "the current view"

      • all data selection options should respect the current sort/pagination params

Future

1. shared search patterns with others in the system (like how you can promote a JIRA filter to be exposed to specific JIRA groups)